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NDMA DB SCHEMA, DICOM TO RELATIONAL SCHEMA TRANSLATION, AND 
XML TO SQL QUERY TRANSLATION 



Cross Reference To Related Applications 

[0001] The present application claims priority to U.S. Provisional Application No. 
60/476,1 17, filed June 4, 2003, entitled "NDMA DB SCHEMA, DICOM TO RELATIONAL 
SCHEMA TRANSLATION, AND XML TO SQL QUERY TRANSLATION," which is 
hereby incorporated by reference in its entirety. The subject matter disclosed herein is related 
to the subject matter disclosed in U.S. patent application serial number (Attorney Docket 
UPN-4380/P3179, filed on even date herewith and entitled "CROSS-ENTERPRISE 
WALLPLUG FOR CONNECTING INTERNAL HOSPITAL/CLINIC MEDICAL 
IMAGING SYSTEMS TO EXTERNAL STORAGE AND RETRIEVAL SYSTEMS", the 
disclosure of which is hereby incorporated by reference in its entirety. The subject matter 
disclosed herein is also related to the subject matter disclosed in U.S. patent application serial 
number (Attorney Docket UPN-4381/P3180), filed on even date herewith and entitled 
"NDMA SOCKET TRANSPORT PROTOCOL", the disclosure of which is hereby 
incorporated by reference in its entirety. The subject matter disclosed herein is further related 
to the subject matter disclosed in U.S. patent application serial number (Attorney Docket 
UPN-4382/P3189), filed on even date herewith and entitled <C NDMA SCALABLE ARCHIVE 
HARDWARE/SOFTWARE ARCHTTECTURE FOR LOAD BALANCING, 
INDEPENDENT PROCESSING, AND QUERYING OF RECORDS", the disclosure of 
which is hereby incorporated by reference in its entirety. 

Field Of The Invention 

[0002] The present invention generally relates to data transformation and, more particularly, 
to transforming data to provide compatibility between DICOM compatible systems and 
NDMA compatible systems. 
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Background 

[0003] Prior systems for storing digital mammography data included making film copies of 
the digital data, storing the copies, and destroying the original data. Distribution of 
information basically amounted to providing copies of the copied x-rays. This approach was 
often chosen due to the difficulty of storing and transmitting the digital data itself The 
introduction of digital medical image sources and the use of computers in processing these 
images after their acquisition has led to attempts to create a standard method for the 
transmission of medical images and their associated information The established standard is 
known as the Digital Imaging and Communications in Medicine (DICOM) standard. 
Compliance with the DICOM standard is crucial for medical devices requiring multi-vendor 
support for connections with other hospital or clinic resident devices. 

[0004] The DICOM standard describes protocols for permitting the transfer of medical 
images in a multi-vendor environment, and for facilitating the development and expansion of 
picture archiving and communication systems and interfacing with medical information 
systems. It is anticipated that many (if not all) major diagnostic medical imaging vendors will 
incorporate the DICOM standard into their product design. It is also anticipated that DICOM 
will be used by virtually every medical profession that utilizes images within the healthcare 
industry. Examples include cardiology, dentistry, endoscopy, mammography, 
ophthalmology; orthopedics, pathology, pediatrics, radiation therapy, radiology, surgery, and 
veterinary medical imaging applications. Thus, the utilization of the DICOM standard will 
facilitate communication and archiving of records from these areas in addition to 
mammography. Therefore, a general method for interfacing between instruments inside the 
hospital and external services acquired through networks and of providing services as well as 
information transfer is desired. It is also desired that such a method enable secure cross- 
enterprise access to records with proper tracking of accessed records in order to support a 
mobile population acquiring medical care at various times from different providers. 
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[0005] In order for imaging data to be available to a large number of users, an archive is 
appropriate. The National Digital Mammography Archive (NDMA) is such an archive for 
storing digital mammography data. The NDMA acts as a dynamic resource for images, 
reports, and all other relevant information tied to the health and medical record of the patient. 
Also, the NDMA is a repository for current and previous year studies and provides services 
and applications for both clinical and research use. The development of such a national breast 
imaging archive may very well revolutionize the breast cancer screening programs in North 
America. However, the privacy of the patients is a concern. Thus, the NDMA ensures the 
privacy and confidentiality of the patients, and is compliant with all relevant federal 
regulations. 

[0006] To facilitate distribution of this imaging data, DICOM compatible systems should be 
coupled to the NDMA. To reach a large number of users, the Internet would seem 
appropriate; however, the Internet is not designed to handle the protocols utilized in DICOM. 
Therefore, while NDMA supports DICOM formats for records and supports certain DICOM 
interactions within the hospital, NDMA uses its own protocols and procedures for file 
transfer, manipulation, and transport 

[0007] Previous attempt to convert DICOM data formats are described in published U.S. 
Patent Application No. 2002/0143727 (Hu et al.), U.S. Patent Application No. 2002/0143824 
(Lee et al.), and U.S. Patent Application No. 2002/0005464 (Gropper et al.). Hu et al. teaches 
a DICOM-to-XML conversion system that converts the DICOM SR (structured reporting) 
standard into a set of XML DTDs (document type definitions) and sSchemas. Lee et al. 
teaches a conversion system that converts a DICOM formatted file into an XML 
representation. Gropper et al. teaches a method for storing an image, such as a DICOM image 
in a repository. However, none of these documents address formatting DICOM data for 
compatibility with the NDMA. 

[0008] Thus, a need exists for a mechanism that couples DICOM compatible systems to the 
NDMA and that provides compatibility of data transferred between the systems. There is also 
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a need for this mechanism to maintain privacy, security, and not hamper operations on the 
hospital/clinic side (DICOM) or the NDMA side. 

Summary Of The Invention 

[0009] A translation scheme that translates DICOM content to a format compatible with an 
NDMA compatible relational database employs a schema for indexing the DICOM content, 
and employs a mechanism for translating queries embedded in XML to SQL (structured query 
language). The translation scheme translates DICOM content to a relational database, a 
schema for indexing the DICOM content, and a mechanism for translating queries embedded 
in XML to SQL. The translation scheme translates DICOM compatible data into a tab 
delimited flat representation of the DICOM content The flat representation of the DICOM 
content is then translated into data compatible with a relational database format, such as SQL. 
The database compatible representation is then formatted into database insert commands. The 
scheme enables capture of the DICOM information into relational, tables. 

[001 0] The translation scheme further provides compatibility of data transferred b etween 
DICOM compatible systems and NDMA compatible systems and databases. This scheme 
maintains privacy, security, and does not hamper operations on the hospital/clinic side 
(DICOM). This scheme also maintains encryption on the external network side, provides 
strong authentication, and external management, and can efficiently handle transfers of large 
amounts of data between the DICOM system and the NDMA Also, the scheme allows 
incoming XML and DICOM content to be stored and indexed in the archive (NDMA), 
automatically accepts any DICOM content and indexes it, and provides query/retrieve 
mechanisms specified in XML. 

[001 1] The translation scheme in accordance with an exemplary embodiment of the present 
invention, transforms DICOM compatible data to data compatible with an NDMA compatible 
relational database by transforming the DICOM compatible data into an intermediate format 
The intermediate formatted data is then formatted into data compatible with the NOMA 
compatible relational database format 

--4-- 
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Brief Description Of The Drawings 

[0012] Figure 1 is a block diagram of firewalled hospital systems coupled to a WallPlug via 
a TCPDP compatible network, secured query devices and GRID connections coupled to an 
archive, and an archive coupled to the WallPlug via a virtual private network in accordance 
with an embodiment of the present invention; 

[0013] Figure 2 is a block diagram of the NDMA Archive System in accordance with an 
embodiment of the present invention; and 

[0014] Figure 3 is a diagram depicting the translation process in accordance with an 
exemplary embodiment of the present invention. 

Description Of Embodiments Of The Invention 

[0015] In an exemplary embodiment of the present invention, the translation scheme is 
implemented in a system comprising a DICOM compatible system (e.g., at a hospital or 
clinical institution), an NDMA compatible system comprising at least one relational database 
for storage and retrieval of archived information (e.g., digital mammography images), and a 
WallPlug coupling the two systems. 

[0016] Figure 1 is a diagram illustrating a firewalled hospital system 14 coupled to a 
WallPlug 12 via a TCPIP compatible network 1 8, secured NDMA query devices 22 and 
GRID connections 24 coupled to an NDMA archive 16, and the archive 16 coupled to the 
WallPlug 12 via a virtual private network 20. Grid compatible systems use Open Grid 
Standards for system authentication and for locating and using services, and NDMA 
compatible systems use NDMA protocols for authentication and acquiring services . The 
NDMA archive 16, as depicted in Figure 1, accepts streams of NDMA protocol wrapped 
DICOM and DICOM SR (DICOM structured report) content from the front end of the 
WallPlug 12 and stores the content on large scale storage media (e.g., databases 26, 28, and/or 
30) while simultaneously and automatically indexing the DICOM header and DICOM SR 
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content in a relational database 28. WallPlugs, such as the WallPlug 12, are portal systems 
used to couple the NDMA archives (e.g., archive 16) with the DICOM compatible systems 
(e.g., hospital system 14). For a better understanding of the WallPlug 12, please refer to the 
related application entitled, "CROSS-ENTERPRISE WALLPLUG FOR CONNECTING 
INTERNAL HOSPITAL/CLINIC MEDICAL IMAGING SYSTEMS TO EXTERNAL 
STORAGE AND RETRIEVAL SYSTEMS", Attorney Docket UPN-4380/P3 179, filed on 
even date herewith, the disclosure of which is hereby incorporated by reference in its entirety. 
The archive 16 also accepts streams of NDMA protocol wrapped queries which can be 
executed against the relational database to extract DICOM and DICOM SR content and return 
it to the WallPlugs 12. The archive 16 also accepts GRID protocols for storage retrieval and 
services. 

[0017] The WallPlug 12 has two network connections. One is connected to the hospital 
network 18 and the other is connected to an encrypted external Virtual Private Network 
(VPN) 20. The WaUPlug 12 also presents a secure web user interface and a DICOM hospital 
instrument interface on the hospital side and a secure connection to the archive on the VPN 
side. The WallPlug 12 makes no assumptions about external connectivity of the connected 
hospital systems. 

[0018] The archive 16 can be coupled to any of several network configurations. That is, the 
archive 16 has multiple modes of network connection. In one configuration, the archive 16 is 
coupled to the hospital networks via the encrypted VPN 20 attachments to WallPlugs 12. In 
another configuration, the archive 16 is coupled to the secured query stations 22. In yet 
another configuration, the archive 16 is coupled to the GRID systems 24. Each configuration 
utilizes a network, a transport protocol, and some middleware. The middleware can form a 
portion of the archive 16, a connection point, or a combination thereof. Incoming items for 
storage are translated from NDMA 19 or GRID 17 protocols and stored in medical records 
stores 26, and all content is indexed in a database 28. Incoming queries for storage are 
translated from NDMA 19 or GRID 17 protocols and retrieved from medical records stores 
26, using automatic translation of the XML query syntax applied to indices in a database 28. 

--6~ 
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Incoming requests for services are translated from NDMA 19 or GRID 17 protocols and 
applied to stored items in the medical records stores 26 or received items, and all results are 
indexed in a database 28. All requests for storage, retrieval, or services are audited by an 
audit process 25, and all actions are recorded by the audit software 23 in audit database 30 
which can be either separate from or the part of the storage/retrieval database 28. Properly 
secured external devices 22 are those which have a browser enabled by a client certificate 
issued by NDMA or by a browser authenticated by smartcard or other security devices and 
authentication tokens issued by NDMA, and which are allowed in the NDMA security tables. 
These devices can execute queries against the data using the NDMA protocol The translation 
in this case from an internal web query to the NDMA protocol is accomplished through an 
externally accessible WallPlug 12. Grid Access devices 24 connect to the archive through a 
Grid protocol translation 17 which interfaces to NDMA protocols. Storage requests are 
translated from NDMA protocol to DB commands through the NDMA Storage Protocol 
Translation 19 and query requests are translated through the NDMA query Protocol 
Translation 21. 

[0019] Figure 2 illustrates an overview and the basic components of the archive (NDMA) 
system 16 for storage, indexing and retrieval. Incoming storage requests are handled by a 
storage receiver 60 of which there may be one or several instances distributed across one or 
more machines. The load balancer (senders) 62, of which there can be many, push incoming 
storage requests to Storage nodes 64 using any appropriate load balancing technique. Storage 
nodes 64 store files in their managed file spaces 68 and indices in the database 66. At the 
conclusion of a successful store, a reply message is generated and placed in the reply queue 
(not shown in Figure 2). This reply is automatically routed by the Reply Pusher 78 discussed 
below. 

[0020] Incoming query requests are handled by a request receiver 70, of which there can be 
one or several instances distributed across one or more machines the same as or different from 
the machines handling the storage requests. The load balancer (senders) 72, of which there 
can be many, push incoming query requests to the request nodes 74 using any appropriate 
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load balancing technique. The request nodes 74 query the indices 66 and locate all files 
necessary to satisfy the request. In the case of files managed locally, the files are fetched and 
formatted according to NDMA protocols by the Reply Manager 76. Completed replies are 
sent to the reply pusher 78 which routes them back to the requesting location. For files which 
are not local, the Reply Manager 76 sends the protocol elements back to the load balancer 72 
which directs the request to the reply manager 76 on the node which controls the data. This 
node then completes the process by fetching the requested file, attaching the protocol 
elements, and sending the file to the reply pusher. The latter more complicated procedure is 
used to maintain record level independence and to avoid direct network traffic crossing 
between request nodes. 

[0021] Figure 3 is a diagram depicting the translation process in accordance with an 
exemplary embodiment of the present invention. As illustrated in Figure 3, the XML 
wrapped DICOM content (represented by block 34 of Figure 3) comprises incoming content 
and requests that have NDMA protocol XML headers and DICOM content For a better 
understanding of this protocol, please refer to the related application entitled, "NDMA 
SOCKET TRANSPORT PROTOCOL", Attorney Docket UPN-4381/P3180, filed on even 
date herewith, the disclosure of which is hereby incorporated by reference in its entirety. The 
text and binary components of the XML wrapped DICOM content 34 are split by the 
XML/DICOM splitter process 36 into DICOM components and XML components. Note that 
storage requests contain binary DICOM components. The binary DICOM components are 
processed by the DicomDump process 38, which converts DICOM content to an intermediate 
format 48 for further translation. In the intermediate format 48, the DICOM content is 
organized into items comprising a group and an element The DICOM (group, element) items 
50 are translated via database tables to a relational database representation 52 containing 
identifiers for the database, the table, and the column (database, table, column), and to 
database commands 54. Referring again to the XML/DICOM splitter process 36, the XML 
components containing authentication information are used to determine whether access is 
allowed for queries 40 or for storage 41 requests and to additionally locate storage locations 
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for storage requests and queries 44. Queries continuing XML representations of DICOM 
(group, element) queries and/or NDMA items are translated to (database, table, column) 
representation 42 and then to database queries 45. Storage requests are translated to database 
commands 47 which include items prepared from the binary DICOM 56. 

DicomDump 

[0022] The DicomDump process 3 8 is the first step in the DICOM to relational database 
index translation. In an exemplary embodiment, versions of the software developed to 
implement the DicomDump process 38 are compatible with WINDOWS® and UNIX® based 
platforms. The DicomDump process walks through (traverses) a DICOM or DICOM SR file 
and verifies the file for legitimate format and produces a standardized output file or memory 
resident structure. The file or memory resident structure is used to display information in the 
file. It is also used as input into the first step of populating an index for the information. This 
intermediate format is a flat representation of the data which is tab delimited for subitems and 
CR/LF (carriage return/line feed) delimited for items. It can be serialized into a flat file. The 
intermediate output has the form (group in hex, element in hex) (tab) (length in bytes) (tab) 
VR (value representation) (tab) Description (tab) Content (CR/LF)- An exemplary 
intermediate format is shown below. In the list below, the binary DICOM content has been 
translated to a group element "(2, 0)", followed by the length of the data for that group, 
element "( 4)" followed by a type indicator (VR) "UL" followed by a description "Group 
0002 Length" followed by the actual content "178". VR is a DICOM defined descriptor of 
the data type of the value for the group/element pair. For example, (group, element) equal to 
(8,23) has a VR of DA which identifies the specified value of "2000503" as a date, i.e. May 3, 
2000. 
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[0023] DicomDump example output in intermediate format 

Filename C:\MARecv\127.0.0.1^isqpI^ A 4600^estfile 

2, 0)( 4) UL Group 0002 Length 178 
2, 1)( 2) OB File Meta Information Version 
2, 2)( 28) Ul Media Stored SOP Class UID 
12.840.10008.5.1.4.1.1.12 
2, 3)( 48) Ul Media Stored SOP Instance UID 
12.840.113619.2.76.2158572937.561.959791758.941 



1.2.840.10008.1.2 
1.2.40.0.12.0.9907 



2, 10)( 18) Ul Transfer Syntax UID 
2, 12) ( 18) Ul Implementation Class UID 
2, 13) ( 12) SH Implementation Version Name 
8, 5)( 10) CS Specific Character Set ISOJR100 , 

8, 8)( 18) CS Image Type ORIGINAL\PRIMARY\ 
8, 16)( 28) Ul SOP Class UID 
1.2.840.10008.5.1.4.1.1.1.2 
8, 18)( 48) Ul SOP Instance UID 
1 .2.840.1 136192.76.2158572937.561 .959791758.941 



20000503 
20000503 

20000503 
20000503 

150032.000000 

150433.000000 
150542.000000 

150554.000000 



8, 20) ( 8) DA Study Date 

8, 21) ( 8) DA Series Date 

6, 22) ( 8) DA Acquisition Date 

8, 23) ( 8) DA Image Date 

8, 30) ( 14) TM Study Time 

8, 31) ( 14) TM Series Time 

8, 32) ( 14) TM Acquisition Time 

8, 33) ( 14) TM Image Time 

8, 50) ( 0) SH Accession Number 

8, 60) ( 2) CS Modality 

8, 68) ( 16) CS Presentation Intent Type 

8, 70) ( 18) LO Manufacturer 

8, 80) ( 6) LO Institution Name 

8, 90) ( 12) PN Referring Physician's Name 

8,1010) ( 10) SH Station Name 

8,1 030) ( 8) LO Study Description 

8,103e) ( 6) LO Series Description 

8, 1 050) ( 2) PN Attending Physician's Name rs 

8,1 070) ( 2) PN Operator's Name jg 

8,1 090) ( 8) LO Manufacturer's Model Name ADS J .0 

8,21 1 2) ( 0) SQ Source Image Sequence 
;fffe,e000)( 0)DLItem 

8,1 1 50) ( 30) Ul Referenced SOP Class UID 

1.2.840.10008.5.1.4.1.1.12.1 

8,1 1 55) ( 50) Ul Referenced SOP Instance UID 

12.840.1136192.662159378590.11312000503150544.3 
[fffe,e00d) ( 0) DL Item Delimitation Item 
[fffe.eOdd) ( 0) DL Sequence Delimitation Item 

8,2218) ( 0)SQ Anatomic Region Sequence 
;fffe,e000)( 0)DLItem 

8,100)( 8) SH Code Value 

8, 102) ( 4) SH Coding Scheme Designator 

8, 1 04) ( 6) LO Code Meaning 



MG 

FOR PRESENTATION 
GE MEDICAL SYSTEMS 
SWCHSC 

SWCHSC-AWS 
bil so- 
dense 



T-04000 

SNM3 
BREAST 
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fffe.eOOd) ( 0) DL Item Delimitation Item 

Iffie.eOdd) ( 0) DL Sequence Delimitation Item 

10, 10) ( 0) PN Patient's Name 

10, 20) ( 22) LO Patient ID 

IOP2679.896.959791 758 

10, 30) ( 0) DA Patienfs Birth Date 

10, 40) ( 2) CS Patient's Sex F 

10.1000) ( 0) LO Other Patient IDs 

1 0.1 001 ) ( 0) PN Other Patient Names 
1 0,1 040) ( 0) LO Patienfs Address 

1 0,21 54) ( 0) SH Patienfs Telephone Numbers 

18, 15) ( 6) CS Body Part Examined BREAST 

18, 60) ( 2)DSKVP 29 

1 8,1 020) ( 48) LO Software Versions 

Ads Application Package xxxx VERSION ADS_8.12.1 

1 8.1 1 1 0) ( 4) DS Distance Source to Detector 660 

18.1111) ( 4) DS Distance Source to Patient 660 

18,1 1 14) ( 2) DS Estimated Radiographic Magnification Factor12.1 1 

18,1147) ( 10) CS Field of View Shape RECTANGLE 

18.1 149) ( 8) IS Field of View Dimensions 229M91 

18.1 150) ( 4) IS Exposure Time 1024 

18.1151) ( 2) IS X-ray Tube Current 73 

18.1 152) ( 2) IS Exposure 72 

18.1 153) ( 6) IS Exposure in uAs 72200 
18,1 160) ( 6) SH Filter Type STRIP 

1 8,1 1 64) ( 8) DS Imager Pixel Spacing 0.1\0.1 

18,1166) ( 24) CS Grid 
RECIPROCATING\PARRALLEL 

18.1 190) ( 4) DS Focal Spot 0.3 

18.1191) ( 8) CS Anode Target Material RHODIUM 
18,11a0)( 2) DS Body Part Thickness 43 

1 8, 1 1 a2) ( 2) DS Compression Force 50 

18.1400) ( 6) LO Acquisition Device Processing Descriptionor12.1 PROCJ 

1 8.1401 ) ( 14) LO Acquisition Device Processing Code GEMS_FFDMJFC_1 
1 8,1 405) ( 2) IS Relative X-ray Exposure 6 

1 8,1 508) ( 1 2) CS Positioner Type MAMMOGRAPHY 

1 8,1 51 0) ( 2) DS Positioner Primary Angle 0 

18,1530) ( 2) DS Detector Primary Angle 0 

18,1700) ( 12) CS Collimator Shape RECTANGULAR 

1 8,1 702) ( 2) IS Collimator Left Vertical Edge 0 

18,1704) ( 2) IS Collimator Right Vertical Edge 0 

18,1706) ( 2) IS Collimator Upper Horizontal Edge 0 

1 8,1 708) ( 2) IS Collimator Lower Horizontal Edge 0 

18,5101) ( 2) CS View Position CC 

1 8.7000) ( 4) CS Detector Conditions Nominal Rag YES 

1 8.7001 ) ( 4) DS Detector Temperature 36.8 

1 8.7004) ( 1 2) CS Detector Type SCINTILLATOR 

1 8.7005) ( 4) CS Detector Configuration AREA 
18,700a) ( 12) SH Detector ID &FFDM1.8.3 
18,701a) ( 4) DS Detector Binning 1\1 

1 8,7020) ( 1 0) DS Detector Element Physcal Size 1 92\230.4 
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18,7022) ( 8) DS Detector Element Spacing 0.1 \0.1 

1 8,7024) ( 10) CS Detector Active Shape RECTANGLE 
1 8,7026) ( 1 0) DS Detector Active Dimensions) 1 92\230.4 

1 8,7030) ( 4) DS Field of View Origin 5\1 
1 8,7032) ( 2) DS Held of View Rotation 0 
1 8,7034) ( 2) CS Field of View Horizontal Rip NO 
1 8,7050) ( 8) CS Filter Material RHODIUM 

18,7060) ( 10) CS Exposure Control Mode AUTOMATIC 

1 8,7062) ( 50) LT Exposure Control Mode Description 

AOP dose RECTANGLE 1252 mm 810 mm 100 mm 100 mm 
1 8,7064) ( 6) CS Exposure Status NORMAL 

20, d)( 48) Ul Study Instance UID 
1 .2.840.1 1361 9.2.76.2158572937.561 .959791758.939 

20, e)( 48) Ul Series Instance UID 
1 .2.840.1 13619.2.76.2158572937.561 .959791758.940 

20, 10) ( 4) SH Study ID 103 

20, 11)( 4) IS Series Number 176 

20, 13) ( 2) IS Image Number 2 

20, 20) ( 4) CS Patient Orientation A\R 

20, 62) ( 2) CS Image Laterality L 

28, 2)( 2) US Samples per Pixel 1 

28, 4)( 12) CS Photometric Interpretation MONOCHROME2 

28, 10) ( 2) US Rows 2294 

28, 11)( 2) US Columns 1914 

28. 1 00) ( 2) US Bits Allocated 1 6 

28. 1 01 ) ( 2) US Bits Stored 1 2 

28. 102) ( 2) US High Bit 11 

28. 1 03) ( 2) US Pixel Representation 0 
28, 300) ( 2) CS Quality Control Image NO 
28, 301 ) ( 2) CS Burned In Annotation NO 

28.1040) ( 4) CS Pixel Intensity Relationship LOG 

28.1 041 ) ( 2) SS Pixel Intensity Relationship Sign -1 

28.1050) ( 14) DS Window Center 2335\2353\2311 

28.1051) ( 12) DS Window Width 750\600\900 

28.1 052) ( 2) DS Rescale Intercept 0 

28.1053) ( 2) DS Rescale Slope 1 

28.1 054) ( 2) LO Rescale Type US 

28.1055) ( 20) LO Window Center & Width Explanation NORMAL\HARDER\SOFTER 
28,21 10) ( 2) CS Lossy Image Compression 00 
40, 302) ( 2) US Entrance Dose 0 
40, 306) ( 4) DS Distance Source to Entrance 61 7 
40, 31 0) ( 4) ST Comments on Radiation Dose 76 % 
40, 31 6) ( 8) DS Organ Dose 0.01471 
40, 31 8) ( 6) CS Organ Exposed BREAST 
40, 555) ( 0) SQ Acquisition Context Sequence 
45, 10) ( 12) Unknown GEMS_SENO_02 
45,101b) ( 4) Unknown LCC 
45,1020) ( 10) Unknown 1360.5325 
45,1026) ( 1024) Unknown 

( 45,1029) ( 14) Unknown 1265V4.4000001 
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45,102a) ( 12) Unknown -1 

45.102b) ( 12) Unknown -1 

45.1049) ( 2) Unknown 50 

45.1050) ( 50) Unknown 



1 .2.840.1 1 361 92.66.21 59378590.1 6720005031 50554.1 2 
45,1051) ( 54) Unknown 

1 .2.840.1 1 361 9.2.66.21 59378590.1 1 3120005031 50433.1 0004 



( 45,1058) ( 


10) Unknown 


0.80000001 


( 45,1059) ( 


4) Unknown 


2088 


( 45,1060) ( 


14) Unknown 


0\1172\1172\0 


( 45,1061) ( 


18) Unknown 


349\349\2189\2189 


( 45,1062) ( 


12) Unknown 


2029 


( 45,1063) ( 


12) Unknown 


1667 


( 45,1064) ( 


2) Unknown 


31 


( 54. 220) ( 


0) SQ View Code Sequence 




(fffe.eOOO) ( 


0) DL Item 




( 8.100)( 


8) SH Code Value 


R-10242 


( 8,102)( 


4) SH Coding Scheme Designator 


SNM3 


( 8.104)( 


14) LO Code Meaning 


cranio-caudal 


( 54. 222) ( 


0) SQ View Modifier Code Sequence 


(fffe.eOOd) ( 


0) DL Item Delimitation Item 




(fffe.eOdd) ( 


0) DL Sequence Delimitation item 




( 88. 200) ( 


0) SQ Icon Image Sequence 




(fffe.eOOO) ( 


0) DL Item 




( 28, 2)( 


2) US Samples per Pixel 


1 


(28. 4)( 


12) CS Photometric Interpretation 


MONOCHROME2 


( 28. 10) ( 


2) US Rows 


64 


( 28, 11) ( 


2) US Columns 


53 


( 28, 100) ( 


2) US Bits Allocated 


16 


( 28, 101) ( 


2) US Bits Stored 


14 


( 28, 102) ( 


2) US High Bit 


13 


( 28, 103) ( 


2) US Pixel Representation 


0 


(7fe0, 10)( 


6784) OW Pixel Data 


[39306784] 


(fffe.eOOd) ( 


0) DL Item Delimitation Item 




(fffe.eOdd) ( 


0) DL Sequence Delimitation Item 





(2050, 20) ( 8) CS Presentation LUT Shape IDENTITY 
(7fe0, 10) ( 8781432) OW Pixel Data [ 10754 8781432 ] 

DICOM (group, element) translation 

[0024] The next step in the construction of a relational database index of the DICOM 
content is to translate the intermediate format into an SQL insert (SQL compatible format) at 
DB command translation step 54 (Figure 3). In an exemplary embodiment, the DICOM items 
are translated into table column names. This is accomplished by using a column name that is 
easily derived from the DICOM item. The column name used for an item in the intermediate 
format as (group, element) = ( gg, ee) is HggHee. For example, a patient name which is a 
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group 10 element 10, i.e., (10, 10 ), is encoded in a column having the column name H10H10. 
This translation allows one to automatically derive a column name for any DICOM group 
element combination in the DICOM record. 

[0025] Utilizing the translation scheme in accordance with the present invention, any 
DICOM data item can be associated with a column name. Also, each column is associated 
with a database table name. This assignment is table driven and a lookup function returns the 
table name for each (group, element) including a default table as described below. 

Level 1,2,3 tables 

[0026] La the NDMA database schema of the invention, a level of interest is associated with 
each data element There are three levels of interest The first level contains data elements 
that are most likely to be used in subsequent queries and therefore are preferably optimized. 
These include items such as patient name, patient ID, date of birth, attending physician, etc. 
These content items are placed in two tables, tbljtnain, and tbl_dicom_smalL These and the 
other table to follow are located in the indices table 28. The second level of interest contains 
elements of interest that may be queried, but with less frequency than elements in the first 
level of interest These items are contained in tbl_dicom_all_a, tbl_dicom_all_b, 
tbljiicom_all_c, tbljttcom_all_d, tbl_dicom_all_e, tbl_dicom_all_£ and tbl_dicom_all_jj. 
Items are grouped in these tables based on the likelihood that they would be used 
simultaneously in a query. This arrangement of multiple tables keeps the tables small and the 
grouping helps eliminate table joins for queries. The third level of interest table comprises all 
other elements. Because this table may also include sequence items, and because it is able to 
store arbitrary (group, element) items, the table is a rotated one, i.e. it has a foreign key, and 
an entry for each (group, element) encountered. The table name is tbljdicomjrest. 

Location tables 

[0027] For each record stored, there is also recorded the machine, data system, and file 
name of the stored record. This information is stored in a table named tbllocations. This 
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table can have multiple locations to enable the storage of primary records, backup copies, and 
cached content on other servers. A listing of sample tables follows. 

[0028] LUBIRADS 

The LUJ3IRADS table is used to determine the relationships among between the following 
items: 

• automated DICOMJDUMP name of a BIRADS item (BI001 thru BI126) BiRADS is 
the standard for the results of an exam - this standard was established by the American 
College of Radiology] 

• common name of the item (used for printing reports) 

• NDMANAME (XML tag for an item) 

• Datatype 

This table allows NDMA to translate BiRads records to table entries and XML tags to BiRads 
elements in such a way that additional customized elements can be added to these medical 
records as necessary. 

[0029] LUJPortals 

This table contains the identifying information for portals allowed to connect to the system. It 
contains: 

• Portal ID 

• Certificate Hash 

• IP address 

• Hostname 

• Common Name (used for reports) 

[0030] LU_portals_Gnraps 

This table is used to assign portallDs to PortalGroups. 

A need arises in NDMA to determine whether hospital enterprises are or are not willing to 
exchange records. Portal groups represent groups of portals that will exchange data. 
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[0031J LUDICOMJMCT 

This table is used to drive the DICOMJXJMP. Table elements include: 

• GROUPELEMENT ( for example H10H10) 

• Type (standard DICOM twochar types) 

• CommonName 

• NDMANAME ( allows XML to use common names rather than GROUPELEMENT) 

• TableName (table where item is indexed) 

• Level 

This table provides a flexible, expandable and customizable translation between XML tags 
and DICOM elements. 

[0032] LUJVONJHCOMJHCT 

This table includes definitions of other non-DICOM names: 

• FieldName 

• Type 

• CommonName 

• NDMANAME 

• TableName 

• Level 

[0033] LU_Groups 

This table is used to identify portal groups: 

• GroupID 

• CommonName 

[0034] LUGroup_Allow 

This table is used to control data exchange between groups. 
[0035] LUJLocations 

This table Storage locations - identifies storage locations of possible node storage systems: 

• LOCID 

• IP 

• Storage level 

• dirName 

• LibName 
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[0036] LU_Storage_LeveIs 

This table includes a list of possible storage levels. 

[0037] TBL_Audits 

This table includes MPPA Audit table for Queries: 

• AUDITID 

• Action 

• RequestDD 

• RecordID 

• TimeStamp 

• ActorFaciKty 

• ActorlD 

• ActorCERT 

[00381 TBLJLocations 

This table includes a data locator for the actual file, including, for example: 

• RecID 
. • LocID 

• FileName 

• TapeName 

• FileMarks 

• RecoidMarks 

• BlockSize 

[00391 TBL_Log 

This table is the general table for log entries: 

• TimeStamp 

' • DebugLevel 

• MachineName 

• Process 

• SubProcess 

• Action 

• Actionlong 

• ItemDescription 

• Result 

• ResultLong 

[00401 TBLJMcomJSmall 

This table stores the most frequently searched items: 
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• RecID 

• H8H5, H8H8, H8H18, H8H20, H8H50, H8H60, H8H64, H8H80, H8H90, H8H100, 
H8H102, H8H104, H8H1010, H8H1030, H8H103E, H8H1050 

• H10H10,H10H20,H10H30,H10H40,H10H1010 

• H18H15,H18H5101 

• H20HD,H20HE,H20H10,H20H11,H20H13 

• H28H301 

• PatientAge 

[0041] TBLJMain 

• This table includes the following: Recid 

• Fonnat 

• FileLength 

• DateArrived 

[0042] TBL_DICOM_ALL_A thru G 

This table includes RecID followed by columns of the HjjjHkkk form. 
[0043] TBLDICOMJRest 

This table includes all DICOM items not found in small, or ALL_A thru ALL_G. 
[0044] TBLJUniqueJD 

This table includes a lock mechanism for the database. 
TBLJXML 

This table includes the contents of the original XML Header: 

• RecID 

• OriginalTP 

• OriginalTimeStamp 

• OriginalMessageNumber 

• REQID 

• SenderFacility 

• SenderlD 

• SenderCert 

[0045] As explained in related application entitled, "NDMA SOCKET TRANSPORT 
PROTOCOL", Attorney Docket UPN-4381/P3180, the NDMA protocol headers contain 
XML headers that form a virtual "envelope" for the DICOM transmission of a record The 
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database stores information fiom this header. The storage processor strips the envelope from 
the record, but preserves it in the file system. 

XML to SQL Query translation 

[0046] To enable queries of the medical records database 26 and/or the audits database 30, 
the ability to automatically translate an incoming XML expressed query into an SQL query 
appropriate for the internal database representation is implemented in accordance with the 
inventioa This translation step provides security and efficiency benefits. First, the incoming 
XML is verified for correct formatting. Second, the translation blocks any attempt to execute 
arbitrary queries on the database. Third, it verified appropriate authorization and release 
criteria is verified for cross-enterprise requests, and fourth, it provides a mechanism to 
optimize query SQL. An example of the XML quay syntax is shown in Table 1, below. 
Items in XML tags are translated to internal database names and tables (e.g., H10H10 in 
tbl_dicom_small). The query requirements can then be constructed including any required 
table joins. One purpose of the resulting internal SQL query is to identify record IDs that are 
then used in the locations tables to extract content Content is automatically wrapped in the 
NDMA transport protocol and returned to locations specified in the original query. The 
process of query construction is table driven so the relationship between external XML tag 
names and internal database column names can be flexible. 

[0047] The query translator 21 (Figure 1) currently recognizes two different types of 
queries: research and clinical. Clinical queries are searches for patient records based on 
patient identifying information such as name, birthdate, internal hospital ID or others. 
Research queries can search for groups of patients whose records satisfy some criteria. 
Research requests are assumed to span across patients, and results are returned grouped into 
visits where a visit is specified as a name-date-facility combination, e.g., a patient seen on a 
particular date at a particular facility. Research request records are anonymized when 
returned by replacing patient names with an identifier constructed from the request number, 
the sequential patient number within the research records, and a trailing "NDMA". 
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Additionally, all identifiers are removed as specified for de-identified records according to 
HPAA regulation. 

[0048] The query translator in the case of research requests also searches the database for 
any additional reports or visits by the same patient at either the same facility or any other 
facility. Patients are linked between facilities by name, birthdate, and in some cases medical 
record number. 

[0049] Special cross-reference records can be entered into the database to facilitate name 
and/or medical record number changes. 

Special Columns 

[0050] The database storage routines provide for special values that can be stored in the 
index 28 as calculated values. This is done to facilitate rapid searches on quantities derived 
from the primary data but not directly contained in the records. One such example is patient' 
age at time of exam. This is calculated when the data is received from the study date and the 
patient birthdate, both of which are contained in the DICOM record. The result is stored in a 
PatientAge column in the database. One reason for this is that this is a value that is expected 
to be frequently requested in research queries, and it would be inefficient to recalculate it or 
attempt to store it in a database view. 

[0051] An example XML store request is presented below, followed by Table 1 - An 
Example XML Query. The XML store request illustrates a message type, i.e., Storeimage, 
message identifier including the originating address, time stamp and originating message 
number. This is followed by the requested action for the message including identifier and 
priority description of authorization of sender including senders certificate and senders 
requesting facility identifier. This is followed by a description of the intended receiver, 
receiver certificate, and IP address, followed by a description of the payload including 
payload type and items of interest extracted from payload including patient identifiers and 
other items. 
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Example XML Store Request 

<?xml verslon= w 1.0" encoding="UTF-8" ?> 

<Message type="StoreImage n > 
<MessageID> 

<OrlginalIP>130.91.51.20</OriginalIP> 
<Tlmestamp>5/12/2003 9:00:01 AM</Timestamp> 

< Messag eN u m > - 1343 2 </Messag eN u m > 
</MessageID> 

<Request action= n Store n type="Image a > 

<ID>-13432</ID> 

<Priority>Routine</Priority> 

</Request> 
<Sender> 

< Certiflcate>xxxxxxxxx</Certlficate> 
<Requestor> 

<Facility>NSCP</Facility> 
<ID>NSCP-6007</ID> 
</Requestor> 
</Sender> 
<Receiver> 

<Certificate> xxxxxxxxx </Certificate> 
<IP>130.91.51.20</IP> 
</Receiver> 
< Pay load > 

<Record type=°Image n format="DICOM ,, > 
<Item> 

<Name>PatientID</Name> 
<Value>pId_745566</Value> 

</Item> 
<Item> 

<Name>NamePatientFuII</Name> 
<Value>dummy_745566</Value> 

</Item> 
</Record> 
</Payload> 
</Message> 



[0052] The table below shows an example ofNDMA protocol headers together with an 
XML query. Following the NDMA header, the XML specifies a Message type (in this case 
"(^yClinicaT'). That is followed by characteristics of the message including originator IP 
address, timestamp and message reference number. Next comes identifier information about 
the sender and the individual making the request, and them The next XML 
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item specifies the action requested which in this case is a quay including the query priority. 
Finally in the payload section is an XML specification of the query to be performed including 
values and items requested and operators that specify the logic of the query. This payload is 
translated by 42 for execution against the database. 



Table 1 - Example XML Query 

NDMA/VERSION: 1.0 
CONTENT-TYPE: XML 
CONTENT-LENGTH: 877 

<?xml version= n 1.0" encodings" UTF-8 n ?> 
<Message type="QueryClinical n > 
<MessageID> 

<OriginalIP>192 . 168 . 5 . K/OriginalIP> 

<Timestamp>1049898878</Timestamp> 

<Mes sageNum>2 0 8 0 6< /Mes s ageNum> 

</MessageID> 

<Sender> 

<Certif icate> XXXXXXXXX </Certif icate> 
<Requestor> 

<Facility>SWCHSC</Facility> 

<ID>Bob Hollebeek</ID> 

<Certif icate> XXXXXXXXX </Certif icate> 

</Requestor> 

</Sender> 

<Receiver> 

<Certif icate> XXXXXXXXX </Certif icate> 

<Ip>192 . 168 . 0 . 1</Ip> 

</Receiver> 

<Request act ion= "Query" type="Clinical n > 

<ID>20806</ID> 

<Priority>LOW</Priority> 

</Request> 

<Payload> 

<CriteriaGroup operator="AND n > 
<CriteriaItem operator= n EQUAL"> 
<Name>NamePatientLast</Name> 
<Value>XXXXXXXX /N </Value> 
</CriteriaItem> 

<CriteriaItem operator="EQUAL n > 

<Name>Facility</Name> 

<Value>SWCHSC</Value> 

</CriteriaItem> 

</CriteriaGroup> 

</Payload> 

</Message> 
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[0053] As illustrated in Figure 3, A translation scheme for translating DICOM content to a 
format compatible with an NDMA compatible relational database in accordance with 
embodiments of the present invention transforms the DICOM compatible data into an 
intermediate format and then transforms the intermediate formatted data into data compatible 
with the NDMA compatible relational database. The translation scheme in an exemplary 
embodiment translates DICOM compatible data into a tab delimited flat representation of the 
DICOM content The flat representation of the DICOM content is translated into a relational 
database format, such as SQL. The database compatible representation is then formatted into 
database insert commands. The scheme enables capture of the DICOM information into 
relational tables. The DICOM content items are copied from but not removed from input 
records. Thus hospital records are preserved exactly as sent to the NDMA and as produced by 
the DICOM devices. 

[0054] Arriving records are stored and indexed in the archive database in accordance with 
the index structured database schema. The DICOM content and private NDMA items are 
represented in XML. The XML is translated into database internal table and column 
representations. Arriving records, whether transported via NDMA or GRID compliant 
mechanisms, are automatically converted. The record contents comprising XML and DICOM 
components in an NDMA protocol or GRID wrapped NDMA protocols in a GRID protocol 
are automatically converted into database commands for storage in the archive medical 
records database 26. Arriving requests for content, whether transported via NDMA or GRID 
compliant mechanisms, are automatically converted. The requests for content comprising 
XML components in an NDMA protocol or GRID wrapped NDMA protocols in a GRID 
protocol are converted into database commands for query and retrieval in the archive 
database. The NDMA saves the XML transmission "envelopes" for fixture use in rebuilding, 
replicating, or moving archives. 

Two types of queries are supported and distinguished by XML content in the request The 
XML is easily extended to define additional types. The first type is a request for Clinical 
records. The second type is a request for research records. Queries are processed as 

— 23-- 



WO 2005/001623 



CA 02528492 2005-12-02 



PCT/US2004/017848 



described in accordance with Figure 3 and requested records are passed to a "Reply Manager" 
76 (Figure 2). This process groups records into visits and identifies them as such in the 
returned XML headers along with the attached binary DICOM content wrapped in the NDMA 
protocol Each record is individually returned with its own wrapper. The visit identifiers can 
be used to group records which share characteristics such as patient name, birthdate, patient 
ID and study date. Records returned from a query are of two types, differentiated by 
identifiers in the XML portions of the NDMA protocol. Clinical records are not de-identified, 
but research records are. All records are returned through the "ReplyPusher" process 78 
(Figure 2). The Reply Manager 76 for research requests returns records as part of a two step 
process. In the first step, only de-identified visit and report information is returned, but binary 
DICOM image content is not. The reply manager 76 encrypts locator information for the 
partially returned information in case the requestor wishes later to retrieve a de-identified 
copy of the image. The encrypted locator provides a stateless mechanism for retrieving this 
additional content and does not require re-execution of any database commands to locate the 
records. In a subsequent request, the requestor can reference the encrypted locator, which will 
instruct the Reply Manager 76 to pull the requested records and send them through the 
ReplyPusher78. 

[0055] Many features are provided by the translation scheme described herein. The 
DICOM binary records are automatically translated into an intermediate format which is used 
as an interface between the binary formats and database processes. The DICOM (group, 
element) tags are automatically translated into database column and table names in an 
extensible manner. The DICOM (group, element) items are automatically categorized into 
levels of interest that control how they populate database tables. This enables more rapid 
index searching. The NDMA can calculate certain quantities during index creation and add 
them to the index to enable future searches based on these quantities. The list of such items is 
extensible. The NDMA database provides location information concerning the record 
provider which forms a virtual file room for an enterprise's data. The NDMA database 
supports isolation or sharing of data from one enterprise to another. A mechanism is provided 
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for verifying authorization of the movement of records across enterprise boundaries. The 
NDMA provides an XML syntax for record queries and automatically verifies the syntax. 
The verified and authorized XML specified queries are automatically translated into 
optimized SQL. The NDMA also provides a method whereby infrequently used DICOM 
(group, element) tags can nevertheless be stored in the database for future queries. The 
NDMA provides a mechanism for storing BiRADs content in the relational database. The 
NDMA also provides a mechanism for querying BiRADS information to form de-identified 
collections of research visits whose summary information can be displayed at the hospital. 
The NDMA provides a state-less method for allowing hospitals to select a subsample from 
de-identified summaries and to acquire de-identified records for such cases from the medical 
records archive 26. 

[0056] Although illustrated and described herein with reference to certain specific 
embodiments, the present invention is nevertheless not intended to be limited to the details 
shown. Rather, various modifications may be made in the details within the scope and range 
of equivalents of the claims and without departing from the invention- 
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Claims 

What is Claimed: 

1 . A method for transforming digital imaging and communications in medicine (DICOM) 
compatible data into national digital mammography archive (NDMA) relational database 
compatible data, said method comprising the steps of: 

transforming said DICOM compatible data into data formatted in accordance with an 
intermediate format; and 

transforming said intermediate formatted data into data compatible with said NDMA 
compatible relational database. 

2. A method in accordance with claim 1, further comprising the steps of: 

parsing searchable and indexable elements of a DICOM header of said DICOM 
compatible data; and 

transforming said parsed elements into components of said intermediate format 

3. A method in accordance with claim 2, further comprising the step of: 

transforming each of said components of said intermediate format into one of a table 
indicator, a column indicator and a command compatible with said relational database. 

4. A method in accordance with claim 3, further comprising the steps of: 

associating each column of said relational database with a database table in 
accordance with a level of interest of DICOM compatible data in said column. 

5. A method in accordance with claim 4, wherein said level of interest includes at least one 
of: 

a first level of interest indicative of DICOM compatible data most likely to be queried; 
a second level of interest indicative of DICOM compatible data less likely to be 
queried than said first level of interest; and 
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a third level of interest indicative of DICOM compatible data that is not included in 
said first and second levels of interest 

6. A method in accordance with claim 5, wherein : 

DICOM compatible data belonging to said third level is indexable in said database. 

7. A method in accordance with claim 1, wherein said DICOM compatible data comprises 
extensible markup language (XML) formatted text, said method further comprising the step of 
transforming said XML formatted text into data compatible with said NDMA compatible 
relational database. 

8. A method in accordance with claim 7, wherein said XML text comprises XML requests 
and said relational database supports structured query language (SQL) queries contained in 
said XML requests. 

9. A method in accordance with claim 1, wherein: 

said DICOM compatible data comprises at least one of NDMA protocol wrapped 
DICOM data, DICOM structured reports, selected DICOM compatible data, and an 
Open Grid Standard compatible request 

10. A method in accordance with claim 9, wherein: 

said Open Grid Standard compatible request comprises at least one of a service 
request, a storage request, and a retrieval request 

11. A method in accordance with claim 1, wherein said intermediate format comprises a tab 
delimited flat representation of said DICOM compatible data. 

12. A method in accordance with claim 11, further comprising the step of serializing, 
wherein said intermediate format is serializable. 
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13. A method in acccordance with claim 1 1, wherein said intermediate format comprises: 

a group and element indicator indicative of a group and element, respectively, to 
which said DICOM compatible data belongs; 

a length indicator indicative of a length of said DICOM compatible data; 
a value representation of said DICOM data; and 
a description of said DICOM compatible data. 

14. A method in accordance with claim 13, wherein said DICOM compatible data comprises 
at least one group/element pair, said method further comprising for each pair: 

translating DICOM items into table column names; 
appending an identifier "H" to a beginning of each group; 
appending an identifier "H" to a beginning of each element; 
concatenating said appended group and said appended element; and 
associating each concatenated group/concatenated element with a column of a 
relational database. 

15. A method in accordance with claim 1, wherein: 

only authorized DICOM compatible data is transformed; and 

authorized DICOM compatible data is transformed into selected relational database 

indicators to ensure efficient querying of said relational database. 

16. A method in accordance with claim 1, wherein DICOM compatible data is transformed 
for only authorized enterprises. 

17. A method in accordance with claim 1, wherein: 

responsive to a clinical query for transformed DICOM compatible data, DICOM 
compatible data having patient identification information is provided; and 
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responsive to a research query for transformed DICOM compatible data, de-identified 
DICOM compatible data is provided 
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